DID Masking

Network administrators can assign Direct Inward Dialing numbers to AudioCodes’ media gateway so that PSTN network users can directly reach VoIP network users. The gateway connects the PSTN network to the VoIP network, routing and translating calls between the two. A call from a PSTN user is directed to the VoIP user who holds the corresponding DID number.

The feature has two main applications:

■

It masks the enterprise’s internal phone numbers while allowing return calls to the original caller. A bank, for example, can use the feature to change an employee’s phone number to the bank’s global number so that when a customer calls the global number back, they’ll directly call the same employee who originated the call.

■

It changes the outgoing phone number to a local phone number of the destination location from a predefined pool of numbers while allowing return calls to the original number which is in a different location; this opens a private use case.

The feature supports calling an emergency service (E911) using the local number of a user who is not located in that country / region and also supports receiving a return call from the emergency service. For example, an employee visiting a different office branch must call an emergency service. The call in this case is originated with the telephone number of the branch and when the emergency service operator calls back, they’ll get to the employee who called.

The capability is achieved by saving the mapping between the original source number, the destination number and the number used to hide the original caller. This mapping is shared across all the ARM Routers so no matter which ARM Router received the return call, it will be routed to the original caller.

The mapping is saved in a Redis database which operates in a master-slave mode. By default, the master is in the ARM Conifigurator and the slaves are in the ARM Routers. Each Router has its own Redis instance. The mapping of the outgoing call is saved in the master Redis instance which is replicated to each ARM Router. The incoming call is first looked up in the local Redis instance before going to the master Redis instance. This reduces delay and network traffic.

The default master location can be changed. This should be done mainly for large enterprises whose CPS is high enough to put a high load on the ARM Configurator.

➢

To enable DID in the ARM:

1.

In the ARM GUI’s Web Services page (Settings > Call Flow Configurations > Web Services), add a new Web Service.

2.

Define 'Agent type' (the type of web service for the DID masking feature); in the preceding figure it is defined as did_masking.

3.

Define the service’s parameters using the following as a reference:

●

Implementation name: The name of the web service; the name will be used in the ARM’s Policy Studio.

●

Query Timeout: The timeout of the lookup for a call, in milliseconds.

●

Connect timeout: The master Redis instance’s timeout. After the time expires the master is indicated as unavailable from the ARM Router’s perspective. The time is in milliseconds.

●

Password: The password of the master Redis instance

●

Use Configurator as master: By default, this option is selected; the ARM Configurator is by default used as the master of the Redis instance. If the option is cleared, a new option is displayed for the host and the port of the new master.

●

Redis debug level enabled: By default, this option is cleared. The option enables more detailed logging in the Redis.

4.

After you Submit, add a Prefix Group of a new type ‘Pool of Numbers’ and then define a pool of numbers that will be used as the DID masking numbers, as shown in the next figure:

Add a Prefix Group of New Type 'Pool of Numbers'

5.

Define the group’s parameters using the following as a reference:

●

'Type': Must be set to Pool of Numbers. When the Prefix Group is of this type, the numbers inside will be handled as full numbers (as if they ended in a #).

●

'Numbers': Defines the numbers inside the pool.

6.

Define a new Policy Studio of action type ‘Web Service’. Select the DID masking web service and then configure:

a.

a condition for when to perform masking (under 'Match')

b.

the direction of the call, either outgoing or incoming, per the matching condition because the ARM doesn’t have the capability to ‘find’ the direction of a call.

c.

Source and Destination normalization for the lookup operation; this only manipulates the URIs for the Redis and has no effect on the URI for the routing operation.

If the direction of the call is outgoing, the following must be configured:

d.

Pool of numbers from which the manipulated number will be picked. The field can remain empty. If left empty, the ARM will not perform any manipulation but will simply save the destination and source number mapping which is useful in cases when the manipulation itself is performed after the ARM routing.

e.

Call expiration time

f.

The flow of the Policy Studio

After creating an outgoing Policy Studio rule, the ARM automatically creates an incoming Policy Studio rule above the outgoing rule. The name of the rule will be ‘Callback of Outgoing rule name’. Most attributes will automatically be defined. The rule can be updated to give the operator more control over how the callback is executed.

If the direction of the call is incoming, the following must be configured:

g.

How ARM Routers should look up the incoming call in the Redis:

i.

Source and Destination number

ii.

Only the Source number -or-

iii.

Only the Destination number

Make your selection per your network requirements. For example, if some sort of normalization was performed prior to the ARM routing (e.g., the same destination number for all calls).

Add Call Item - How ARM Routers should look up the incoming call in the Redis

7.

Configure using the following as reference:

●

Web Service: The web service that will be used for the action manipulation.

●

Call direction: The direction of the matched call: Outgoing or Incoming.

●

Source normalization for lookup: Normalization to perform on the Source URI before the operation in the Redis. The normalization has no effect on the URI itself. It’s useful when the Source number changes in one of the directions.

●

Destination normalization for lookup: Normalization to perform on the Destination URI before the operation in the Redis. The normalization has no effect on the URI itself. It’s useful if the Destination number changes in one of the directions.

For outgoing calls:

◆

Pool: The pool of numbers from which the ARM will pick the manipulated number. If this field is empty, the ARM will not perform manipulation and will only save the Source to Destination number mapping.

◆

Call Expiration time: The time a call is saved in the database. Defines the length of time ARM allows a return call before discarding the mapping.

◆

Flow: Defines what the ARM should do after this Policy Studio rule is matched

For incoming calls:

Incoming Calls

8.

Configure using the following as reference:

●

Match incoming calls by: Defines how the ARM looks up a return call that was masked.

◆

Source and Destination number. ARM performs the lookup using a combination of both the caller’s number and the masked number. The original caller will be retrieved only if the return call came from the same destination number that was originally called.

◆

Destination. This is a looser lookup option. The ARM performs it using the masked number. The last number masked to the number is retrieved, allowing a return call from any calling number to the number from the pool. It’s typically used for E911 scenarios in which the E911 operator’s source number doesn’t have to be the E911 number.

◆

Source. ARM performs the lookup by the Source number. This option is useful when the Destination number is a static number (like E911) and identification of the call can only be performed using the Source number. The latest number mapped to the number is retrieved.

In the preceding figure, for example, the Policy Studio rule will mask all outgoing calls from prefix ‘+033’ with numbers from the pool ‘pool for DID traffic’ and save the mapping for the return call for one hour.

When an incoming call matches any number in the pool, the ARM retrieves the original number that initially called and replaces the destination with the original number.